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Beschreibung 

Verfahren zum Ubermitteln von geschiitzten Informationen an 
mehrere Empfanger 

5 

Fachgebiet der Erfindung 

Die Erfindung betrifft ein Verfahren gemali der unabhangigen 
Anspruche 1 und 2. 

In den vergangenen Jahren ist es inimer popularer geworden, 
iiber die verschiedenen Kommunikationsnetze Dienste in An- 
spruch zu nehmen oder Waren zu erwerben. Ein Hinderungsgrund 
war fiir den Benutzer bisher immer, dass auch sensible Daten, 
wie Kontoinformationen, iiber das Netz ubertragen werden miis- 
sen. 

In der Figur la ist ein Kaufvorgang vorgestellt, wie er der- 
zeit beispielsweise im Internet durchgefuhrt wird. Auf der 
einen Seite steht der Kunde (Consumer), der bei einem Verkau- 
fer (Merchant) Waren erwirbt. Die Bezahlung dieser Waren soil 
iiber sein Bankkonto erfolgen. Der Kunde iibermittelt nun seine 
Warenanforderung an den Verkaufer, hier sind verschiedene In- 
formationen denkbar, wie Zusatzinformationen iiber den Kunden 
(Zusatzinfo) , eine Angabe iiber die gewiinschten Waren (Goods)/ 
sowie Information iiber die gewiinschte Zahlunsweise, bei- 
spielsweise eine Kreditkartennummer . 

Diese Informationen werden dem Verkaufer iibermittelt, etwa 
iiber eine gesicherte Leitung (SSL, Secure Socket Layer, und 
TLS, Transport Layer Security, eine gesicherte Verbindung) . 
Diese Verbindung kann zwar von Fremden nicht abgehort werden, 
jedoch erhalt so auch der Verkaufer Informationen, die nicht 
unbedingt fiir ihn bestimmt oder zum AbschluJi des Kaufvertra- 
ges notwendig sind, wie eben die Kreditkartennummer. Der Ver- 
kaufer leitet diese Informationen vollstandig an die Bank 
weiter, insbesondere auch die Information iiber die gekauften 
Waren, die nicht fiir die Bank bestimmt sind. 
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Gewiinscht ware jedoch ein Verhalten^ wie es in der Figur lb 
dargestellt ist, so dass der Verkaufer nur die fur ihn wich- 
tigen Informationen uber die bestellten Waren erhSlt und die 
Bank nur die fur sie wichtigen Informationen uber das Konto 
5 des Kunden. 

Stand der Technik 

10 Verschiedene Losungen sind bereits bekannt, Ein bekanntes 
Produkt auf deni Gebiet der elektronischen Bezahlverfahren 
wird von der Firma SET Secure Electronic Transactions Lie. 
angeboten. Eine Beschreibung des bekannten Verfahrens findet 
man in der Spezifikation der Software, die auf ihrer Webseite 

15 http: //www . setco , org/extensions , html abgelegt sind. Hier fin- 
det sich eine Datenstruktur, die durch zusatzliche Erweite- 
rungen^ sogenannte "extensions'% anwendergerecht erganzt wer- 
den kann. 

20 Auch in dieser Losung von SET wird jedoch keine Moglichkeit 
angegeben, verschiedene inhaltlich zusammengeh5rende Informa- 
tionen, beispielsweise Kreditkartennummern mehrerer Anbieter 
Oder Kontoangaben verschiedener Banken, zusammen in einer Da- 
tenstruktur abzulegen. 

25 

Aufgabe der Erfindung ist es also, ein Verfahren zum Ubermit- 
teln von Informationen anzugeben, welches es den Empfangern 
ermoglicht/ die fur sie bestimmten Telle der Informationen zu 
lesen. Aufgabe ist es weiterhin, mehrere inhaltlich zusammen- 
30 gehorige Daten in einer einzigen Datenstruktur geschiitzt zu 
ubermitteln. 

Diese Aufgabe wird gelost durch ein Verfahren gemali des Pa- 
tentanspruchs 1 und durch ein Verfahren gemali des Patentan- 
35 spruchs 2. 

Gemafi dem Patentanspruch 1 werden erste Informationen, die 
fiir einen ersten Empfanger, im weiteren auch Anbieter ge- 
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nannt, bestinunt sind, zusanunen mit zweiten Informationen, 
welche fvir einen zweiten Anbieter bestlmmt sind, in einer ge- 
meinsamen Informationseinheit versendet. Die ersten Informa- 
tionen konnen dabei gemafl den Vorgaben des ersten Anbieters 
verschlusselt sein. Die zweiten Informationen, welche aus 
mehreren Bestandteilen bestehen konnen, warden gemafl den Vor- 
gaben des zweiten Anbieters verschlusselt, beispielsweise mit 
einem offentlichen Schlussel, einems sogenannten "public 
key". Diese "public key" Verschliisselungsverfahren sind be- 
reits in verschiedenen Ausfiihrungen und Sicherheitsstufen be- 
kannt. Durch dieses Vdrgehen wird gewahrleistet, dass der 
erste Anbieter bei Erhalt der kompletten Information die fiir 
ihn nicht bestimmten Informationsanteile nicht entschliisseln 
kann. 



Der Empfanger der Nachricht wird im weiteren auch Anbieter 
genannt, da in den beschriebenen Beispielen im wesentlichen 
auf einen Kaufvorgang im Netz eingegangen wird. Hier ist der 
erste Empfanger der Nachricht ublicherweise ein Verkaufer, 
also ein Anbieter von Waren und Dienstleistungen, der zweite 
Empfanger der Nachricht eine Bank oder Geldinstitut, also ein 
Anbieter von Finanzdienstleistungen . Diese Beschreibungen 
sind jedoch nicht einschrankend gemeint. 

Andere Konstellationen sind vorstellbar, beispielsweise ein 
25 Anbieter von Informationen, der auf weitere Datenbanken zu- 
greift, ein erster Netzbetreiber, der auf ein Netz in einem 
fremden Land zugreift, ein Automobilhersteller oder Polizei, 
die auf die Datenbank der Kf z-Anmeldestelle zugreifen. 

30 Patentanspruch 2 gibt eine alternative Losungsmoglichkeit an, 
bei der die Informationen, welche fur den zweiten Anbieter 
gedacht sind, nicht mit den ersten Informationen zusammen in 
das Netz geschickt werden, sondern bei Bedarf von dem Infor- 
mationsempfanger aus einem zentralen Speicherbereich im Netz 

35 abgeholt werden konnen. 
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Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den 
Unteranspruchen angegeben. 

Als besonders vorteilhaft hat sich eine Realisierung der er- 
findungsgemafien Losung gemafi dem bereits bekannten Standard 
5 X.509 erwiesen (Series X: Data Networks and Open Systems Com- 
munication - Directory: Public Key an Attribute that Certifi- 
cate Frame Works, ITU-T Recommendation X,509) . Eine Realisie- 
rung mit dem X.509-Standard birgt raehrere Vorteile in sich, 
denn dieses Vorgehen ist bereits standardisiert, und kann un- 
10 abhangig von bereits vorhandenen Implementierungen verwendet 
werden. Eine Definition der Datenstrukturen erfolgt in ASN.l 
Notation, welche ebenfalls seit Langem standardisiert ist und 
implement ierungsunabhangig angewendet wird. 

15 Besonders vorteilhaft erweist sich das erfindungsgemaBe Ver- 
fahren bei den bereits angesprochenen Zahlungstransaktionen, 
die notwendig werden, wenn man Daten, Inforroationen und Waren 
tiber das Internet oder ein sonstiges Kommunikationsnetz be- 
stellt Oder bezieht und auch die Bezahlung uber das Netz ab- 

20 wickeln mochte. 

Im Rahmen der bereits bekannten Transaktionen iiber Netze hat 
es sich bewahrt, einem Vorgang eine sogenannte Transaktions- 
nummer (TAN) zuzuweisen, welche einen Kaufvorgang iro Netz 
25 eindeutig beziffern und auch nachtraglich zuriickverfolgen 
lassen. 

Die Realisierung der Information durch Ablage in einer Erwei- 
terung eines Zertifikats gemaB dem Standard X.509 kann in 
30 zwei verschiedenen Variationen erfolgen. 

Man kann dieses Zertifikat als sogenanntes Identity Certifi- 
cate realisieren, dieses ist beschrieben im ITU Standard 
X.509, Section 2. Vorteilhaft ist bei dieser Ausfuhrungr dass 
35 das Zertifikat sehr kompakt wird, man hat eine "all in one"- 
Losung. 
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Ein Zertifikat in dieser Form ist allerdings im Nachhinein 
nicht mehr anderbar. Daher gibt es als Alternative die Reali- 
sierung in einem sogennannte "Attribute Certificate". Die Be- 
schreibung hierzu findet sich in der Section 3 des bereits 
5 genannten Standards. Das hat den Vorteil, dass die einzelnen 
Erweiterungen (Extensions) dieses Zertifikats unabhangig von- 
einander sind/ deshalb kann man sie jederzeit andern. Ein 
Zertifikat muss auch nicht widerrufen werden/ man muss nur 
abwarten, bis seine Lebensdauer abgelaufen ist. In diesem 
10 Fall wird das System allerdings komplexer. Der Benutzer muss 
verschiedene Zertifikate behandeln und der Ausgebende der 
Zertifikate muss mehr Certificate Revocation Lists (CRL) ver- 
wait en. 

Wahlt man zur Realisierung die zweite Losung, die Attribute 
15 Certificate Extension^ so hat man hier noch die Auswahl, ob 
dieses Zertifikat genau einmal verwendet werden kann, eine 
sogenannte "One Time Use" oder als sogenannte "Long Life Use'' 
einen bestimmten Zeitraum vorgibt, in dem das Zertifikat giil- 
tig ist. 

20 

Zur Ablage des Zertifikats und dazugehorige privaten SchlUs- 
sel ist ein geeignetes Speichermedium denkbar, auch wenn das 
Zertifikat zentral im Netz abgelegt wird. Der Eigentiimer des 
Zertifikats kann dieses auch auf eine Smart Card oder einen 
25 Smart Dongle, auf einem kontaktlos abzulesendem Speichermedi- 
um Oder ahnlichem speichern. Hierbei ist es besonders vor- 
teilhaftr wenn das abgelegte Zertifikat zusatzlich durch ein 
Passwortr eine PIN usw. vor unberechtigtem Zugriff geschtitzt 
wird. 

30 

Das beschriebene Verfahren kann selbstverstandlich ftir alle 
Nutzerinformationen verwendet werden , neben der Kreditkarten- 
nummer, wie Adresse, Blutgruppe, Versicherungsnummern etc.. 

35 Das vorgeschlagene Vorgehen hat gegenuber dem bereits bekann- 
ten Verfahren verschiedene Vorteile. 
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Eine Verschlusselung und Signierung der Inf ormationen init be- 
reits bekannten Verfahren ist jederzeit moglich. Dadurch wird 
der Schutz vor unberechtigtem Zugriff (die Privacy) der In- 
f ormationen gesichert. 
5 Der Diebstahl von Kreditkartennummernr wie es bisher bei- 
spielsweise durch Abhoren der Kauftransaktion geschah, wird 
welter erschwert. Durch eine zusatzliche Sperre des Zugriff s 
auf gespeicherte Informationen auf dem Speichermedium durch 
Einfuhrung einer PIN wird der Schutz weiter erhoht. 

10 

Kurzbeschreibung der Zeichaungen 

Im Folgenden wird die Erfindung anhand von Ausf iihrungsbei- 
15 spielen erlautert. Dabei zeigen 

Figur la eine Ubersicht tiber die Verbindungen^ die derzeit 
bei einem Kaufvorgang aufgebaut werden, wenn der Kaufer die 
Bezahlung iiber einen Zahlungsdienstanbieter im Netz vornimmt, 

20 

Figur lb zeigt denselben Vorgang^ wenn das erf indungsgeraafie 
Verfahren auf den Zahlungsvorgang verwendet wird, 

Figur 2a zeigt die Zertif ikatserweiterungen fiir mehrere Kre- 
25 ditkarten Oder ahnliche Informationen, 

Figur 2b zeigt die neuen Primaten OID gemaB X.660 

Figur 3a zeigt das beispielhafte Format fiir eine Kundenanfor- 
30 derung bei einem Kaufvorgang, 

Figur 3b zeigt das Format fiir die Antwort des ersten Anbie- 
ters, 

35 Figur 3c zeigt das Format fiir die signierte Erwiderung des 
Kunden, 
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Figur 3d zeigt das Format fiir die Authentisierungsdaten voin 
zweiten Anbieter^ ebenfalls signiert, 

Figur 3e zeigt das Format fur eine zweite Kundenanforderung, 

5 

Figur 3f zeigt das Format fiir eine dritte Kundenanforderung, 

Figur 3g zeigt das Format fiir eine vierte Kundenanforderung, 

10 Figur 3h zeigt ein weiteres beispielhaf tes Format fiir die Au- 
torisierungsdaten vom zweiten Anbieter^ ebenfalls signiert, 

Figur 4 zeigt einen Kaufvorgang in vier Schritten^ 

15 Figur 5 zeigt einen Kaufvorgang in acht Schritten, 

" v-:. Figur 6 zeigt einen Kaufvorgang in zehn Schritten^ 

Figur 7 zeigt einen Kaufvorgang rait auftretenden Fehlern^ 

20 

Figur 8 zeigt die Struktur des SICRYTT Secure Token, 
Figur 9 zeigt die X.509 Zertifikat Extension Struktur. 

25 Die Figuren la und lb zeigen, wie in der Einleitung bereits 
beschrieben^ den beispielhaf ten Ablauf eines Kaufvorganges. 
In den Kasten iiber den Pfeilen dargestellt, sind die jeweili- 
gen Informationen, die zwischen den einzelnen Verfahrensteil- 
nehmern fliefien. Der Kontakt des Kaufers (Consumer) geschieht 

30 immer iiber den Verkaufer (Merchant) . Eine direkte Kommunika- 
tion des Kaufers zur Bank findet nicht statt. Alle Informati- 
onen fliefien iiber den Verkaufer. Dies hat zur Folge, dass der 
Verkaufer auch Informationen erhalt, die fiir seinen Verkaufs- 
vorgang unerheblich sind. Durch das erfindungsgemaBe Verfah- 

35 ren^ wie in Figur lb dargestellt, werden dem Verkaufer zwar 
samtliche Informationen iibersendet, er kann diese jedoch 
nicht uneingeschrankt lesen. Beispielsweise die Zahlungsin- 



wo 200S/01S514 



PCT/EP2004/051749 



8 

formation (z.B. Kreditkarten-Nununer, Credit Card Info), wie 
hier durchgestrichen dargestellt, ist dem Verkaufer nicht an- 
gezeigt. Andere Informationen, etwa wer der Kunde ist (Zu- 
satz-Info, User Info) und was dieser Kunde bestellen niSchte 
5 (Waren, Goods) sind ihm frei zuganglich. 

Heutige Public Key Zertifikate versuchen, ein Zertifikat 
(Public und Private Key) auf ein vollstSndiges Userprofil ab- 
zubilden. Allerdings hat sich die Anzahl der Anwendungen er- 

10 weitert, so dass mehr als eine Anwendung (in Zusanunenhang mit 
beispielsweise Webdiensten) benotigt werden. 
Die erfindungsgemafie Idee verwendet hierfUr ein bereits be- 
kanntes X.509 Zertifikat und erweitert dieses durch zusStzli- 
che Inf ormationen . Diese Informationen werden verschliisselt 

15 und in dieser Form im Zertifikat abgespeichert . Eine Darstel- 
lung hierfiir findet sich in Figur 2a. 

Der urspriingliche X.509 Standard wurde entworfen, um einen 
weltweit einheitliche Namen zu entwickeln fiir Benutzer in ei- 
nem Netz, ohne doppeltes Vorkommen/ in einem sogenannten 

20 X.500 Directory. Das X.500 Directory ist eine Datenbank, die 
fiir weltweiten Gebrauch bestinunt ist, wie ein weltweites Te- 
lefonbuch. Das X.509 Zertifikat wird digital signiert und 
durch eine Zertif izierungsautoritat ausgegeben, um die Iden- 
titat des Inhabers und zusatzliche Informationen zu bestati- 

25 gen. Public key Verfahren sehen vor, um sicher rait anderen 

Telnehmer zu kommunizieren, zwei Schlussel zu generieren: ein 
privaten Schlussel (der geheim bleibt) und einen offentlichen 
Schlussel, der an jeden weiter geben werden kann. Das X.509 
Zertifikat verbindet den offentlichen Schlussel und den Namen 

30 des Inhabers des privaten Schlussels. 

Vorteil des X.509 Standards ist es, dass er fiir eine allge- 
meine Verwendung entwickelt wurde. Hier wird das ganz allge- 
meine Problem der Authentisierung in verteilten Systeraen ge- 
lost und sein Losungsentwurf ist implementierungsunabhangig . 

35 

In der Version 3 des X.509 Standards, der 1996 verof fentlich 
wurde, wurden sogenannte Extensions eingefUhrt, bei denen je- 
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dermann zusatzliche Datenfelder implementieren und diese in 
seine Datenstruktur einfiihren kann. Diese Erweiterungen wer- 
den auch Private^ Proprietary, oder Custom Extensions ge- 
nannt. Sie tragen eindeutige Informationen, die fur den Zer- 
5 tif ikatinhaber oder Zertif ikataussteller wichtig sind. 

Bislang bekannte Erweiterungen sind heute sogenannte ''Key U- 
sage Limits"^ die die Verwendung eines Schlussels auf einen 
speziellen Verwendungszweck beschranken, oder "Alternative 
Names''/ die der Verkniipfung des Offentlichen Schlussels (Pub- 
10 lie Keys) mit anderen Namen wie: Domain Namen, E-Mailadressen 
etc. ermoglicht. Diese Zertif ikaterganzungen konnen auch als 
kritisch markiert werden um anzuzeigen, dass die Erganzung 
iiberpriift werden muss. 

15 Im beispielhaften Fall eines Zahlungsverkehrs teilt der Be- 
nutzer mit verschiedenen Teilnehmern verschiedene "Geheimnis- 
' se'% also Daten, die nur dem direkten Kommunlkationspartner 
bekannt gegeben werden sollen, beispielsweise bei einem Kre- 
ditkartenausgebenden^ wie American Express, Visa, Master Card 

20 etc., eine Kreditkartennuromer oder mit einer Bank die Konto- 
nummer oder mit einer Versicherungsanstalt die Versicherungs- 
nuramer. Weitere personliche Informationen, wie beispielsweise 
die Adresse, sind vorstellbar. 

Nur der Besitzer des Zertifikats kennt alle diese Erweiterun- 
25 gen. Jede einzelne Erweiterung wird dann so verschlusselt, 
dass nur die jeweilige Partner mit der richtigen Identitat 
die entsprechenden Daten wieder entschlusseln kann. 

Hierfiir kann beispielsweise das bekannte Public Key Krypto- 
30 graphie-Verfahren verwendet werden. Zur Verschliisselung wird 
dann der jeweilige offentliche Schliissel der Versicherung, 
der Bank oder des Kreditkartenausgebenden verwendet. Dieses 
wird bei der Ausgabe des Zertifikats verwendet. Danach wird 
das Zertifikat in einem Public Directory abgelegt werden, 
35 well nur der jeweilige Ausgebende der Information diese mit 
seinem privaten Schlussel entschlusseln (verstehen) kann. 
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Die Erweiterungen sind in dem X. 509-Standard in der ASN.l No- 
tation definiert. Die Figur 2a zeigt eine beispielhaf te Aus- 
gestaltung einer moglichen ausgegebenen Zertif ilcaterganzung 
fiir einen Benutzer. Dieser Benutzer besitzt drei verschiedene 
5 Kreditkarten (Visa, AmeX, Mastercard) , ein Bankkonto (Bankac- 
count) / weiterhin ist seine Adresse kodiert (Address) und ei- 
ne Versicherungsnummer (Social Insurance Number) . 

Die einzelnen Erweiterung werden durch sogenannte Object I- 
10 dentifier" (OID) identif iziert . Diese ist eindeutig, was be- 
deutet, dass beispielsweise alle Felder, in denen eine Kre- 
ditkartennununer von einem speziellen Kreditkarteninstitut 
(beispielsweise Visa) inuner dieselbe Object ID hat. Im ge- 
zeigten Beispiel der Figur 2b ist diese OID, diese sogenannte 
15 Nununer 1,3. 6. 1.4. 15601.1. Die Definition dieser Object Iden- 
tifier OID befindet sich in der ITU-T Recommendation X-660. 
Die OID kann entweder in einer Baumstruktur abgelegt sein, 
das bedeutet, alle Extensions haben denselben Elternknoten. 
Dieser Fall ist in der Figur 2b dargestellt. Es ist aber auch 
20 moglich, dass die Erweiterungen f irmenabhangig sind. Das be- 
deutet, dass die Erweiterungen an verschiedenen Punktes des 
Baumes eingehangt werden. 

Auch in der Figur 9 findet sich eine Reprasentierung des 
25 X.509 Zertif ikats in Baumstruktur. Weiterhin ist in der Figur 
9 zu entnehmen, dass diese Erweiterung nicht blofi als eine 
Bezeichnung und einem Wert bestehen kann, sondern durch wei- 
tere Informationen erganzt werden kann. Im beschriebenen Fall 
der Figur 9 existiert ein weiteres Feld (Crit.), was symbo- 
30 lisch den Wert "true" oder "false" einnehmen kann. Wird der 
Wert auf true (wahr) gesetzt, so bedeutet dies, dass die Er- 
weiterung als kritisch zu interpretieren ist. Eine mogliche 
Reaktion auf diesen Kritischwert kann sein, dass die Anwen- 
dung, die das Zertifikat erhalt und diese Erweiterung nicht 
35 versteht, das Zertifikat als ungviltig zuriickweisen muss. In 
dem Fall, dass das Flag von kritisch auf false gesetzt ist. 
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kann die Anwendung das Zertifikat trotzdem verwenden, auch 
wenn es diese Extension nicht versteht. 

Die Zertifikate konnen auf verschiedene Weise gespeichert 
5 werden. Standard Verfahren ist^ diese zentral im Netz in ei- 
nem Directory abzulegen. 

Vorteilhafterweise kann der Eigentximer des Zertifikats dieses 
aber auch auf einem geeigneten Speichermedium mit sich tra- 
gen. Eine bekannte Methode zur Speicherung von solchen Infor- 

10 mationen sind sogenannte "Smart Cards". Diese Smart Cards 

sind dem Fachmann bereits bekannt. Vorteil bei der Verwendung 
einer Smart Card ist, dass der Zugrif f auf den Speicher, in 
dem das Zertifikat (eigentlich der private Schlussel) abgelegt 
ist, zusatzlich durch eine PIN oder entsprechendem Pafiwort 

15 geschiitzt werden kann. Im Falle mehrfacher falscher PIN- 
Eingabe wird dann der Zugang zum Speicher der Karte bio- 
ckiert . 

Andere Speichermedien sind jedoch vorstellbar. 

In der Figur 8 findet sich eine Darstellung der Infineon Sic- 

20 ript Secure Token Plattform. Diese Plattform bietet zwei Stu- 
fen an Speicherzugang an. Der Userlevel ist mit einer soge- 
nannten "User PIN" geschiitzt und der zweite Level mit einer 
weiteren "Administrator PIN". Diese "Administrator PIN" kann 
verwendet werden, xim nach mehrfachem falschen Eingeben der 

25 "User PIN" die Karte wieder zu entsperren. 

Das Speichern des Zertifikats auf einer Smart Card hat diese 
Vorteile: 

Sicherheit: 

30 Das X.509 Zertifikat und der zugehorige private Schlussel 

werden in zwei verschiedenen sogenannten "Elementary Fi- 
les" (EF) abgespeichert, siehe Figur 8, Der schreibende 
Zugriff zu der entsprechenden Datei DFcsp ist mit einem Zu- 
gangscode geschutzt. Das Elementary File EFKeypair ist ge- 

35 nauso geschutzt. Jede Anwendung oder jeder Dienst, der den 

Zugriff zu dem privaten Schlussel benotigt, muss genau 
diesen Zugangscode vom Benutzer erhalten. Dahingegen kann 
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die Ablage des EFcertificate inuner gelesen warden, ist also 
nicht geschiitzt. Das Zertifikat in das System zu propagie- 
ren bedeutet in diesem Fall also lediglich das Kopieren 
des Zertifikats zu dem System, 

5 

Mobilitat: 

Smart Cards sand tragbare Speichermedien und wegen ihrer 
Grofie kann der Benutzer sie beisplelsweise in seiner 
Brief tasche mit sich tragen. Weiterhin kann er sie an sei- 

10 nem PC mit einem entsprechenden Lesergerat verwenden, ge- 

nauso an offentlichen Terminals (beisplelsweise in einem 
Internetcafe) . Der Benutzer braucht dabei nicht zu be- . 
fiirchten/ dass der private Schlussel kopiert wird oder im 
System verbleibt. Auch wenn der Benutzer seine Smart Card 

15 verliert/ kann auf diese ohne den Zugangscode (PIN) nicht 

zugegriffen werden. 

Kompaktheit: 

Durch das erf indungsgemafie Abspeichern der verschiedenen 
20 Zahlungsm5glichkeiten (beisplelsweise alle Kreditkarten- 

ntjmmern und alle Kontonummern) auf einer Karte, ist diese 
besonders kompakt. Ein derartiges Abspeichern in einer Da- 
tenstruktur ist dem Fachmann bislang nicht bekannt. Wei- 
terhin konnen weitere Informationen (zum Beispiel die Ad- 
25 resse usw.) integriert werden und machen das Userprofil 

damit noch kompakter, 

Im Folgenden wird nun die Durchfiihrung eines Zahlungsvorgangs 
mit dem X.509 Zertifikat beschrieben. In den Figuren 3a bis 

30 3h sind verschiedene Moglichkeiten der einzelnen Nachrichten 
abgebildet, die vom Nutzer, dem Verkaufer oder der Bank im 
Verlauf des Zahlungsvorgangs benutzt werden konnen. 
Die libermittlung dieser Nachrichten erfolgt beisplelsweise 
iiber das Internet/ andere Mobilfunk- oder Festnetze sind vor- 

35 stellbar. 
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Voraussetzung des Verfahrens ist/ dass bereits durch den Nut- 
zer eine Auswahl des Produkts erfolgt ist, sowie der Preis 
fur dieses Produkt verhandelt wurde. Die Nachrichteneinheiten 
werden auf Application Level beschrieben,das bedeutet, es 
5 sind keine Bytestrukturen angegeben. Weiterhin sind die Teil- 
nehmer des Verfahren^"online", also dauerhaft mit dem Netz 
verbunden. 

In einem beispielhaften ersten Ablauf sind der Kunde (Consu- 
10 mer) , der Verkaufer (Merchant) und die Bank iiber ein Netz, 
beispielsweise das Internet/ verbunden- Dies soil aber keine 
Einschrankung fiir das Verfahren darstellen, andere Verbin- 
dungsmoglichkeiten sind denkbar. Die Schritte 1 bis 10 der 
Figur 6 werden in sequentieller Folge durchlaufen. Dabei wird 
15 angenommen, dass der Austausch des X.509 Zertifikats zwischen 
dem Verkaufer (Merchant) und der Bank bereits geschehen ist. 

1. Der Kunde fordert vom Merchant (Verkaufer) den offentli- 
chen Schliissel an, sofern er ihn noch nicht hat (Request 

20 Cert.) . 

2. Der Verkaufer sendete sein Zertifikat (Send. Cert.) an den 
Kunden . 

25 3. Der Kunde validiert das Zertifikat. Dabei iiberpruft er 

beispielsweise, ob die Zeitgiiltigkeit noch nicht abgelau- 
fen ist, und ob das Zertifikat von einer vertrauenswiirdi- 
gen Autoritat ausgestellt wurde. Dann sendet der Kunde 
seine Kauf anforderung an den Verkaufer (Purchase Order) . 

30 Die Kauf anforderung kann das Format haben, wie es in Figur 

3a dargestellt ist. In diesem Fall sind die Angaben der zu 
kaufenden Waren verschliisselt mit dem offentlichen Schliis- 
sel des Verkaufers (E(Merchantpubiickeyf goods), dagegen ist 
das X.509 Zertifikat nicht verschliisselt. Das Versenden 

35 des X.509 Zertifikats in dieser Nachricht ist optional. Im 

anderen Fall holt sich der Verkaufer dieses Zertifikat aus 
Ginera offentlichen Verzeichnis. Das Zertifikat ist nur in 
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dem Teil verschlusselt, der die Kreditkarteninformation, 
wi.e vorher beschrieben, enthalt. 

4. Der Verkaufer entschliisselt diese Nachricht mit seinem 

5 privaten Schlussel. Er pruft auch hier die Giiltigkeit des 

Zertifikats auf folgende Bedingungen: 

1st das Zertifikat von einer vertrauenswiirdigen Autori- 
tat ausgestelltf 

1st die Lebensdauer des Zertifikats uberschritten, und 
10 - 1st das Zertifikat nicht in der CRL (Certificate Revo- 

cation List) . 

Erfiillt das Zertifikat eines der oben genannten Kriterien 
nicht, so markiert der Verkaufer es als ungiiltig und been- 

15 dete die Sitzung mit dem Kunden. 

AnderenfallSf also wenn das Zertifikat gultig ist^ sendet 
der Verkaufer das Zertifikat des Kunden an die Bank oder 
an den Kreditkartenausgeber (Verify Account) , xim die im 
Zertifikat angegebene Kreditkartennummer zu verif izieren. 

20 Diese Kreditkartennummer ist, wie bereits beschrieben, in 

der privaten Erweiterung des X.509 Zertifikats gespei- 
chert, und dort nur verschliisselt zu entnehmen. 

5. Die Bank uberpriift das vom Kunden empfangene X.509 Zerti- 
25 fikat. Die Uberprtifung beinhaltet: 

Kommt das Zertifikat von einer vertrauenswiirdigen Zertifi- 
katsautoritat, 
- ist das Zertifikat abgelaufen, 

ist das Zertifikat in der CRL (Certificate Revocation 
30 List) und 

hat das Zertifikat die Erweiterungen, die die Informatio- 
nen iiber Kreditkartennummern oder Kontonuramern enthalten. 



Ist das Zertifikat als gultig erkannt, so uberpriift die Bank 
35 nun den in der Erweiterung spezif izierten Account. Ist das 
Konto gesperrt oder liberzogen^ dann sendet die Bank eine ne- 
gative Antwort an den Verkaufer. Es ist vorstellbar^ dass ein 
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vordefinierter Set an Antwortcodes zu jedem moglichen Status 
des Kundenkontos definiert wird^ urn diesen Kundenstatus zu 
propagieren. 

1st jedoch das X.509 Zertifikat auch in diesem zweiten Check 
5 positiv iiberpruft, das heisst, das Konto existiert und ist 
belastbar, so sendet die Bank einen speziellen Code, auch als 
Transaktionsnummer (TAN) bekannt, an den Verkaufer zuriick 
(Transaction Number) • Diese TAN ist in der Kegel eine zufal- 
lige Zahl, die eindeutig diese Transaktion identif izieren 
10 soil. 

Diese Transaktionsnununer kann auch noch mit zwei Flags be- 
wahrt werden, einen ^^Angefordert" und einen ^'Benutzt" Flag, 
Wenn die Transaktionsnununer zu dem Verkaufer gesendet wird, 
dann wird der Zustand auf "Angefordert" gesetzt. So kann die 
15 Bank Falschungsversuche durch Kopieren dieser Transaktions- 
nununer verhindern. Die Bank verschliisselt die Transaktions- 
^ -'nununer mit dem offentlichen Schliissel des Verkaufers und sen- 
det es an den Verkaufer zuriick. 



20 6. Der Verkaufer evaluiert die Antwort der Bank und ent- 
schliisselt diese mit seinem privaten Schlussel. 
Ist die Antwort negativ, so beendet der Verkaufer die Sit- 
zung mit dem Kunden. 

Im anderen Fall, wenn die Antwort positiv ist, so muss ei- 
25 ne Transaktionsnummer von der Bank enthalten sein. Der 

Verkaufer formatiert die Antwort auf die Kaufanfrage des 
Kunden, diese Antwort ist beispielhaft in der Figur 3b 
dargestellt, Enthalten ist hier der Betrag (Amount), der 
Name des Kunden (Client Name), die verschlusselte Konto- 
30 nummer, welche aus dem X.509 Zertifikat entnommen wurde 

(Konto Encrypted) , dann die angeforderten Waren (Waren) 
und die von Bank gelieferte Transaktionsnummer (TN) . Die 
Uhrzeit (Zeit) entspricht der Zeit am Server des Verkau- 
fers und der Name (Name) entspricht dem offiziellen Namen 
35 des Verkaufers, so wie es auch in ublichen Kreditkarten- 

transaktionen verwendet wird. Der Kundenname und das Kun- 
denkonto wird vom Zertifikat des Kunden entnommen. am eine 
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erhohte Privacy zu garantieren, konnen auch die eingefiig- 
ten Waren verschlusselt sein, hier dargestellt durch eine 
Hash-Funktion. Der komplette Datensatz wird dann mit dem 
offentlichen Schliissel des Kunden verschlusselt und zum 
5 Kunden geschickt (Request Sign Order) . Vorteilhafterweise 

speichert der Verkaufer diese Anforderung^ insbesondere 
die Adresse und die Waren (Waren), fiir einen spateren 
Versendungsprozess • 

Der Kunde empfangt die Nachricht vom Verkaufer und sig- 
niert diese digital (Dig. Signatur) . Dieses ist zu erken- 
nen in der Figur 3c. Fur die Signierung verwendet er sei- 
nen privaten Schliissel (Private Key Kunde) . Wahlweise kann 
er mit Hilfe der Hash-Funktion seine Waren iiberprufen. 
Die digitale Signatur spielt hierbei eine doppelte Rolle: 
Zum Einen stellt es sicher, dass die Daten wahren der 0- 
bertragung nicht geandert worden sind und zum Anderen sei- 
tens der angeschriebene Kunde dem Kunden entspricht, der 
die ursprungliche Anforderung gesendet hat. Damit stellt 
es sicher, dass es sich tatsachlich um den Inhaber des 
X.509 Zertifikates handelt. Der Kunde verschlusselt nun 
die komplette Nachricht mit dem offentlichen Schliissel des 
Verkaufers und sendet es an den Verkaufer zuriick (Sign Or- 
der) . 

Der Verkaufer empfangt die verschltisselte Nachricht und 
entschliisselt sie mit seinem privaten Schliissel. Dann ver- 
schliisselt er sie mit dem offentlichen Schliissel der Bank 
Oder des Kreditkarteninstitutes . In diesem Schritt handelt 
der Verkaufer nur in einer Routerfunktion (Verify Sign Or- 
der) . Das Format der Nachricht entspricht demselben wie in 
Schritt 7, siehe Figur 3c. 

9. Die Bank entschliisselt die vom Verkaufer empfangene Nach- 
35 richt mit seinem privaten Schliissel. Danach wird die Sig- 

natur der Kundenanf rage verifiziert. Die Transaktionsnum- 
mer, die in der Nachricht vorhanden sein muss^ muss auf 
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"Angefordert" gesetzt sein, wie vorher geschrieben. Ande- 
renfalls ist dies ein Hinweis, dass der Verkaufer versucht 
hat, die Nachricht zu duplizieren. Nach Empfang der Trans- 
aktionsnununer setzt die Bank das zweite Flag fur die 
5 Transaktionsnununer in seiner Datenbank auf "Benutzt". 

Die Bank generiert nun einen Autorisierungscode und forma- 
tiert die Daten wie in der Figur 3d angezeigt. Uhrzeit 
<Zeit) und Bankname entsprechen dem in Schritt 6 beschrie- 
benem. Sicherheitshalber kann die Bank nun diese Nachricht 
10 digital unterschreiben mit ihrem Autorisierungscode. Die 

koraplette Nachricht wird danach verschlusselt mit Hilfe 
des of fent lichen Schliissels des Verkaufers und an den Ver- 
kaufer gesendet (Auth. Code) . 

15 10. Sofern der Autorisierungscode der empfangenen Nachricht 
positiv ist, versendet der Verkaufer seine Waren oder 
macht den angeforderten Dienst fur den Kaufer verfvigbar. 
Weiterhin zieht er den angeforderten Geldbetrag nun vom 
Kreditkarteninstitut oder der Bank ein, Dann informiert 

20 der Verkaufer den Kunden, dass die Transaktion erfolgreich 

durchgefuhrt wurde (Notification) . Diese Nachricht wird 
wieder mit dem of fent lichen Schliissel des Kunden ver- 
schlusselt. 

25 Der im Vergangenem beschriebene Transaktionsprozess kann aber 
auch in der Anzahl der Schritte reduziert werden (siehe hier- 
fur die Figur 5) . Voraussetzung ist in diesem Fall, dass zwi- 
schen jeweils zwei Teilnehmern, dem Kunden und dem Verkaufer, 
und dem Verkaufer und der Bank, eine sichere Kommunikation, 

30 beispielsweise iiber SSL etabliert ist. Weiterhin wird ange- 
nommen, dass eine gegenseitige Authentisierung, basierend auf 
den X.509 Zertif ikaten, zwischen den jeweiligen Teilnehmern 
bereits geschehen ist. 

35 Die Schritte 1 bis 8 werden sequentiell ausgefiihrt. Das For- 
mat der Datenpakete ist dasselbe wie in dem vorangegangenen 
Beispiel der Figur 6 beschrieben. In diesem Fall besteht kei- 
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ne Erfordernis fiir eine Verschliisselung, da die Verschliisse- 
lung durch die SSL-Verbindung bereits gewahrleistet ist. Des- 
halb spart man in diesem Prozess zwei Schritte ein. Ira Prin- 
zip sind die ersten zwei Schritte des Prozesses in Figur 6 
5 eingespart, so dass der Schritt 1 der Figur 5 dera Schritt 3 
der Figur 6 entspricht. Der Schritt 2 der Figur 5 entspricht 
dem Schritt 4 der Figur 6 und so fort- 

Ein Verkauf svorgang mit einem minimalen Nachrichtenaustausch 
10 ist in der Figur 4 dargestellt. In den beiden vorangehenden 

Beispielen wurde der Vorgang in zwei Schritten durchgefiihrt, 

das Bestellen und im zweiten Schritt die Signierung der Be- 

stellung. Figur 4 zeigt nun einen Vorgang, wo beide Schritte 

in einera Schritt zusaramengefasst werden. 
15 Weiterhin ist in diesem Vorgehen auch keine Transaktionsnum- 

mer der Bank erforderlich. Die Transaktionsnummer wird in 

diesem Fall von dem Kunden selber erzeugt. 

Der Nachrichtenfluss funktioniert im Folgenden: 

20 1. Der Nutzer bereitet eine Anforderung (Sign Kaufanforde- 

rung) vorr er generiert sich eine Transaktionsnummer (die 
in diesem Fall eine wirkliche Zuf allsnummer ist TN) , und 
die gegen Kopierattacken verwendet wird. Das Format der 
Nachricht ist in der Figur 3e abgebildet. Das Feld "Zeit" 

25 reprasentiert die Transaktionszeit beim Kunden. Name und 

Kundennummer sind Werte, die aus dem Zertifikat des Kunden 
X.509 entnommen wurden. Die Sxamme (Betrag) reprasentiert 
die Hohe der Summe dieser Kauftransaktion. 
Der Verkaufer (Merchant) ist als Name oder auch als ID, 

30 wie iiblicherweise in Kreditkartentransaktionen, verwendet. 

Ein Hashwert ermoglicht es, dem Kunden seine Auflistung 
der georderten Waren gegeniiber der Bank zu verschliisseln, 
der Hash-Algorithmus ist dem Fachmann bekannt. 
Weiterhin ist in der Nachricht eine digitale Signatur 

35 (dig. Signatur) enthalten^ die die vorangegangenen Daten 

signiert. Diese Signatur versichert dem Verkaufer und der 
Bank, dass der Kunde die Transaktion selber initiiert hat. 
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und dass er der Besitzer des korrespondierenden privaten 
Schliissels ist und die Transaktionsdaten wahrend der Uber 
tragung nicht geandert worden sind. 

Das Feld "Waren" (Goods) reprasentiert die vom Kaufer aus 
5 gewahlten Waren, die gekauft werden sollen oder auch die 

Dienstleistung, dieses Feld muss fiir den Verkaufer lesbar 
sein, um im Zweifelsfall die Anforderung vervollstandigen 
zu konnen. 

Der Kunde hangt sein X.509 Zertifikat mit dem in den Ex- 
10 tensions enthaltenen verschliisselten Kreditkartennummern 

an die Nachricht an. Wenn diese Nachricht liber das Inter- 
net verteilt wird, dann sollte der Kunde diese Nachricht 
zusatzlich rait dem offentlichen Schliissel des Verkaufers 
verschlusseln . 

15 

2- Der Verkaufer uberpriift das Zertifikat des Kunden auf fol 
gende Bedingungen: 

Ist das Zertifikat von einer vertrauenswtirdigen Autori 
tat ausgegeben, 

20 - ist die Lebensdauer des Zertifikats abgelaufen, und 

ist das Zertifikat in der CRL (Certificate Revocation 
List) . 

Wenn die Uberpriifung des Zertifikats eine Fehlermeldung 
25 produziert, dann markiert der Verkaufer dieses als ungul- 

tig und beendet die Sitzung mit dem Kunden. Der Verkaufer 
hat aufierdem die Moglichkeit, die digitale Signatur zu 
priifen, beispielsweise indem er uberpriift, ob der Kunde 
den entsprechenden privaten Schliissel besitzt. Der Verkau 
30 fer entnimmt das Feld "Waren" (Goods) aus der enthaltenen 

Nachricht um sicherzustellen, dass diese Informationen 
nicht an die Bank gelangen, und leitet die restliche Nach 
richt an die Bank weiter (Verify Sign Order) . 

35 3. Die Bank iiberpruft das X.509 Zertifikat des Kunden auf 
Grund folgender Punkte: 
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1st das Zertifikat von einer vertrauenswiirdigen Autoritat 
ausgestelltr 

ist das Zertifikat abgelaufen, 
ist das Zertifikat in der CRL enthalten und 
5 - hat das Zertifikat die privaten Erweiterungen, die die 

Kreditkartennummer oder Kontonununer des Kunden enthalten. 

Stellt sich das Zertifikat als gultig heraus, so verifi- 
ziert die Bank die digitale Signatur um sicherzustellen, 

10 dass die Transaktion tatsachlich vom Kunden ausgelost wur- 

de. Danach uberpruft die Bank das Konto des Kunden oder 
das Kreditkartenkonto, welches in dem X.509 Zertifikat 
enthalten war. Ist diese Kontonununer gesperrt oder ist das 
Konto iiberzogen, so sendet die Bank eine negative Antwort 

15 an den Verkaufer. Im anderen Fall, also wenn das Konto 

verfiigbar ist, so sendet die Bank eine Antwort (Auth. Co-- 
de) zuriick, wie sie in der Figur 3f dargestellt ist. In 
diesem Fall bezeichnet das Feld "Name" den Namen der Bank 
Oder des Kreditkarteninstituts . Die Bank signiert diese 

20 Nachricht danach mit ihrem privaten Schlussel (signiert 

mit Private Key der Bank) . 

4. Im letzten Schritt macht der Verkaufer nach Erhalt des po- 
sitiven Autorisierungscodes die Waren fur die Kaufer zu- 
25 ganglich oder auch die angeforderten Dienstleistungen (No- 

tification) . Weiterhin zieht er das angeforderte Geld vom 
Kreditkarteninstitut ein. 

Das Protokoll, das in diesem Abschnitt beschrieben ist, kann 
30 beispielsweise auch uber http (HyperText Transfer Protocol) 

Oder https (HyperText Transfer Protocol Secure) ablaufen. Im 

Falle von http sollten die Nachrichten mit dem jeweiligen of- 

fentlichen Schlussel des Absenders verschliisselt werden. 

Falls zwischen dem Verkaufer und der Bank ein anderes siche- 
35 res Netzwerk existiert^ beispielweise ein privates Banknetz 

Oder ein VPN (Virtual Private Network)/ so kann auf eine Ver- 

schlusselung verzichtet werden. 
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Die Figuren 3g und 3h stellen weitere Nachrichtenformate dar, 
die alternativ zu den bereits beschriebenen/ aus den Figuren 
3a bis 3f verwendet werden konnen. Die Nachricht aus der Fi- 
5 gur 3g ist beispielsweise ein anderes Format fiir die Nach- 
richt aus der Figur 3c. Die Figur 3h stellt ein Nachrichten- 
format entsprechend der Figur 3d dar. Dies soil deutlich ma- 
chen, dass die entsprechenden Nachrichtenformate nur bei- 
spielhafter Natur sind und selbstverstandlich beispielsweise 
10 durch erganzende Felder verandert werden konnen. 

Der Prozess, der in Figur 7 dargestellt ist, entspricht im 
Wesentlichen dem Vorgehen der Figur 6 mit der einzigen Aus- 
nahme, dass die negativen Antworten (Return (False) ) bei 
15 fehlgeschlagener Uberprufung von Zertifikaten mit eingefiigt 
sind. 

Eine Realisierung der erfindungsgemaBen Idee wurde bereits 
erprobt. Hier wurde das Windows XP als Betriebssystems ver- 

20 wendet, .NET Studio als Entwicklungsumgebung WES (Web Service 
Enhancements) als ein Extramodul fiir die Erzeugung von X.509 
Zertifikaten. CAPICOM-Module fiir die Manipulation der Zerti- 
fikate, zum Beispiel, Signieren, Entschlusseln^ Verschliis- 
seln, Verifizieren usw. Open SSL fiir die Herausgabe der not- 

25 wendigen Zertifikatextensions. Als Smart Card die Infineon 

Secrypt Smart Card und zugehorigen Tools fiir die Installation 
der Zertifikate. 
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^ Patentanspruche 

1. Verfahren zur Ubermittlung von ersten Informationen (Wa- 
ren) von einem Nutzer (Kunde) eines Telekommunikationsnet- 

5 zes an einen ersten Anbieter (Verkaufer) 

und von zweiten Informationen (X,509 Identity Certificate) 
von diesem Nutzer (Kunde) an einen zweiten Anbieter 
(Bank) , 

bei dem die ersten Informationen <Waren) gemafi Vorgaben 
10 des ersten Anbieters (Verkaufer) verschlusselt sein konnen 
und 

bei dem die zweiten Informationen einen ein- oder mehrtei- 
ligen Bestandteil (Zahlungs Info) enthalten, der gemafi 
Vorgaben des zweiten Anbieters (Bank) verschliisselt ist 
15 und bei dem die Informationen in einer gemeinsamen Infor- 
mationseinheit versendet werden. 

2. Verfahren zur Ubermittlung von ersten Informationen (Wa- 

ren) von einem Nutzer (Kunde) eines Telekommunikations- 
20 netzes an einen ersten Anbieter (Verkaufer) 

und von zweiten Informationen (X,509 Attribute Certifica- 
te) von diesem Nutzer (Kunde) an einen zweiten Anbieter 
(Bank) , 

bei dem die ersten Informationen gemafi Vorgaben des ersten 
25 Anbieters (Verkaufer) verschlusselt sein konnen und 

bei dem die zweiten Informationen einen ein- oder mehrtei- 
ligen Bestandteil (Zahlungs Info) enthalten^ der gemafi 
Vorgaben des zweiten Anbieters (Bank) verschlusselt ist 
und bei dem die zweiten Informationen von dem ersten oder 
30 zweiten Anbieter aus einem von dem ersten und zweiten An- 
bieter zugreifbaren Datenspeicher abgelegt sind. 

3. Verfahren nach Patentanspruch 1 oder 2, 
dadurch gekennzeichnet, dass 

35 zur Ablage der zweiten Informationen eine private Erweite- 

rung eii^' 3 Zertifikates gemafi dem Standard X.509 verwendet 
wird. 
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4. Verfahren nach einem der vorigen Patentanspriiche, 
dadurch gekennzeichnet, dass 

es fiir eine Zahlungstransaktion verwendet wird und die u- 
bertragenen ersten und/oder zweiten Informationen sich auf 
die Zahlungstransaktion beziehen. 

5. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet, dass 

dem Zahlungsvorgang von dem zweiten Anbieter oder von dem 
Nutzer eine eindeutige Transaktionsnumner (TAN) zugewiesen 
wird. 



6. Verfahren nach Patentanspruch 4, 
15 dadurch gekennzeichnet, dass 

eine Identity Certificate Extension verwendet wird. 

7. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet, dass 

20 eine Attribute Certificate Extension verwendet wird. 

8. Verfahren nach Patentanspruch 7, 
dadurch gekennzeichnet^ dass 

ein Attribute Certificate genau einmal verwendet werden 
25 kann. 



9. Verfahren nach einem der vorigen Patentanspriiche^ 
dadurch gekennzeichnet, dass 

zur Ablage des Zertifikats ein geeignetes Speichermedium^ 
insbesondere eine Smart Card, ein Smart Dongle oder ein 
kontaktlos abzulesendes Speichermedium verwendet wird. 



10. Verfahren nach einem der vorigen Patentanspriiche, 
dadurch gekennzeichnet, dass 

das Zertifikat mit einem Passwort geschutzt auf dem Spei- 
chermedium abgelegt ist. 
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FIG 2A 



Attribut 


Encrypted Attribut Erweiterung 


VISA 

American Express(AMEX) 
. MasterCard 
Bank Konto 
Adresse . 

Versicherungsnummer 


E(KviSAPublicKey,CreditCardNumber) 
E(KAMEXPubiicKey. CreditCardNumber) 
^(KMaslerCardPublicKey, CreditCardNumber) 
^(KBankPublicKey, AccountNumber) 
^(KpostPUblicKey. Address) 
E(KinsurancePublicKey.lnsuranceNumber) 



Tabelle 1.1: New certiticate extensions. 



FIG 2B 



OID 


Wert 


1.3. 6.1.4.15601 
1.3. 6.1.4.15601.1 
1.3. 6.1.4.15601.2 
1.3. 6.1.4.15601.3 
1.3. 6.1.4.15601.4 
1.3. 6.1.4.15601.5 
1.3. 6.1.4.15601.6 


Root node of new extensions 

Encrypted value: VISA credit card number 

Encrypted value: American Express credit card number 

Encrypted value: MasterCard credit card number 

Encrypted value: Bank Konto Nummer 

Encrypted value: Adresse 

Encrypted value: Versicherungsnummer 



Tabelle 1.2: New private OlDs. 
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